<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>

<head>
<title>SSF Implementation of BGP-4 v1.5.1</title>
</head>

<body bgcolor="white">

<h2>SSF Implementation of BGP-4 v1.5.1</h2>

<hr width="100%">
<b><font size="+1"><i>Contents</i></font></b>
<dl>
<dt><a href="#background">1 Background</a>
<dt><a href="#implementation">2 Implementation Summary and Notes</a>
<dt><a href="#shortcomings">3 Known Shortcomings</a>
<dt><a href="#config">4 Configuration</a>
<dt><a href="#src">5 Source Code</a>
<dt><a href="#examples">6 Examples</a>
<dt><a href="#test">7 Validation</a>
<dt><a href="#faq">8 Questions and Help</a>
<dt><a href="#references">9 References</a>
<dt><a href="#about">10 Authors</a>
</dl>
<hr width="100%">

<a name="background">
<h3>1 Background</h3>

<p align="justify">
The Border Gateway Protocol (BGP) is the de facto standard inter-domain routing
protocol in today's global Internet.  Its purpose is to build up forwarding
tables (often incorrectly referred to as "routing tables") to be used by a
router when forwarding data packets around an internetwork.  It does so in a
distributed fashion: all routers running BGP in the entire internetwork share
reachability information with each other.  When faced with multiple routes to
the same destination, a selection is made based on several factors, many of
which can be configured by the administrator.  Most commonly, shortest
autonomous system (AS) path length is the primary factor.
</p>

<p align="justify">
"Gateway" is simply a dated term for a router.  A "border gateway", then, is a
router on the "border" of an autonomous system (an administrative domain,
roughly).  That is to say, it handles routing between its AS and neighboring
ASes, but it <i>does not</i> deal with routing internal to the AS (that's left
to intra-domain routing protocols, such as OSPF).
</p>

<p align="justify">
Routing should not be confused with forwarding.  Routing is the process of
building up repositories of information about routes.  Forwarding is the
process of using this information to direct packets toward their destinations
(forwarding is basically just doing a look-up in a table).  It is for this
reason that the term "forwarding table" is preferred to "routing table" when
referring to the repository of route information.
</p>

<p align="justify">
It should be noted that although BGP does not perform intra-domain routing, two
routers in the same AS which both run BGP can communicate with each other using
BGP (in fact, they must).  There are slightly different rules for BGP
communication of this nature, and two communicatiing BGP routers in the same AS
are said to have an internal BGP (IBGP) session with each other.  It should be
noted that IBGP is not a protocol itself, but merely a part of BGP.  Similarly,
BGP sessions between ASes are sometimes referred to as external BGP (EBGP)
sessions, in order to distinguish them from IBGP sessions.  The purpose of IBGP
is to make sure that if there are multiple routers running BGP in the same AS,
the routing information between each of them is kept synchronized.  
</p>

<a name="implementation">
<h3>2 Implementation Summary and Notes</h3>

<p align="justify">
The specifications upon which this implementation is based are given in the
Internet Engineering Task Force's Request for Comments number 1771 (RFC 1771),
"A Border Gateway Protocol 4"&nbsp;<a href="#ref1">[1]</a>. Following are the
details of the implementation and how it differs from this specification.
</p>

<p align="justify">
<b>2.1 IBGP/EBGP</b> This implementation simulates both Internal BGP and
External BGP (see <a href="#background">Background</a>).  Route reflection--an
extension for IBGP--has also been implemented&nbsp;<a href="#ref6">[6]</a>.
(See section 9.2.1 of RFC 1771 for a discussion of Internal BGP.)
</p>

<p align="justify">
<b>2.2 RIB</b> The Routing Information Base (RIB), which stores route
information, is implemented with a type of binary tree called a radix tree (the
specification leaves the specific implementation of the RIB up to the
implementor).  As described in section 3.2 of RFC 1771, there are three
sections to the RIB, each of which has been implemented in compliance with the
specification.
</p>

<p align="justify">
<b>2.3 Messages</b> All message types used by BGP (Open, Update, Notification,
and KeepAlive) contain the same fields as given in the specification, with a
few exceptions.  Fields which specify the length in bytes of a message and any
fields used for authentication have been omitted.  In addition, no attempt is
made to make fields the exact size (in number of bits or bytes) as given in the
specification, as these are irrelevant in the simulation.
</p>

<p align="justify">
<b>2.4 Error Handling</b> No error handling (as per section 6 of the
specification) is implemented.  Error handling is typically used for catching
syntactical errors in messages.
</p>

<p align="justify">
<b>2.5 Update Message Handling</b> The handling of Update messages (the type
which carry route information) is fully implemented.
</p>

<p align="justify">
<b>2.6 Path Attributes</b> All standard path attributes have been implemented,
though some have not been extensively tested.
</p>

<p align="justify">
<b>2.7 Timers</b> All five timers used by BGP are implemented, with time
interval defaults as suggested in Appendix section 6.4 of RFC 1771.
</p>

<p align="justify">
<b>2.8 Jitter</b> RFC 1771 requires that three of the timers be jittered
(Minimum AS Origination, Keep Alive, and Minimum Route Advertisement--see
section 9.2.2.3).  Jitter on any or all of them can be turned off by using the
proper configuration parameters (see Configuration).
</p>

<p align="justify">
<b>2.9 Finite State Machine</b> The primary behavior of BGP is defined in one
method which handles all BGP messages and events (method
<code>BGPSession.handle_event()</code>).  It reacts to the incoming
message/event based on its type and the current state of BGP.  From here, some
helper methods may be called to manipulate the RIB and to compose and send
messages, if necessary.
</p>

<p align="justify">
<b>2.10 Route Reflection</b> Route reflection, which is a BGP extension&nbsp;<a
href="#ref6">[6]</a>, is fully implemented.
</p>

<p align="justify">
<b>2.11 Policy (Route Filtering)</b> This implementation also supports, in
addition to the core required behaviors, a policy configuration (route
filtering) scheme along the lines of those used by well-known vendors and
following the suggestions in RFC 1772&nbsp;<a href="#ref3">[3]</a>.  This
feature has not yet been exercised as fully as most others, and should be used
with care.
</p>

<p align="justify">
<b>2.12 Route Flap Damping</b> Support for route flap damping, as described in
RFC 2439&nbsp;<a href="#ref9">[9]</a> and RIPE 210&nbsp;<a
href="#ref10">[10]</a>, is included.
</p>

<p align="justify">
<b>2.13 Validation</b> All of the required behaviors of BGP have been
implemented to our knowledge, though we are still constantly evaluating and
testing it to attempt to verify its correctness.  To this end, a series of <a
href="#test">validation tests</a> have been composed which exercise these
required behaviors.
</p>

<a name="shortcomings">
<h3>3 Known Shortcomings</h3>

<p align="justify">
<b>3.1 One Advertisement Per Update</b> When multiple prefixes with the same
path attributes are sent to a peer, they are never put in the same update
message even though they could be.  (Updates can contain multilple withdrawals,
however.)
</p>

<p align="justify">
<b>3.2 Unchecked Update Message Size</b> When update messages are sent, the
number of bytes required may exceed the maximum allowed size of 4096.
</p>

<p align="justify">
<b>3.3 No Aggregation</b> Though several parts of automatic prefix aggregation
have been implemented, it is not mature enough to be enabled.
</p>

<a name="config">
<h3>4 Configuration</h3>

<p align="justify">
As with the rest of SSFNet, SSF.OS.BGP4 is configured using DML.  To run BGP on
a router during a simulation, simply add the following DML code to the
<code>graph</code> attribute of the router:
</p>

<blockquote>
<pre>
ProtocolSession [
  name bgp
  use SSF.OS.BGP4.BGPSession
]
</pre>
</blockquote>

<p align="justify">
BGP also requires that Sockets, TCP, and IP are running on the router.  So if
they do not already appear, the following additional
<code>ProtocolSession</code>s should be added after BGP's
<code>ProtocolSession</code>:
</p>

<blockquote>
<pre>
ProtocolSession [
  name socket
  use SSF.OS.Socket.socketMaster
]
ProtocolSession [
  name tcp
  use SSF.OS.TCP.tcpSessionMaster
]
ProtocolSession [
  name ip
  use SSF.OS.IP
]
</pre>
</blockquote>

<p align="justify">
This is the minimal configuration for including BGP in an SSFNet model, though
additional attributes can be specified if the modeler wishes to have more
precise control over the protocol.  Each of these additional BGP-related
options fit into one of three categories of configuration types.  The first is
<i>configuration of behavior</i>.  Options of this type are subdivided into
global and individual options, and control exactly how BGP is to behave during
the simulation.  The second type is <i>configuration of presentation</i>.
Options of this type deal with what output is generated and how it is to be
presented to the user.  Options which configure presentation never affect the
actual behavior of the model.  The third type is <i>configuration of
optimizations</i>, in which certain functionality can be traded off for
improvements in model execution.  In particular, there are several memory usage
optimizations available.

<h4>4.1 Configuration of Behavior</h4>

These options control exactly how BGP is to behave during a simulation.  There
are two categories of behavioral configuration: individual and global.

<h4>4.1.1 Configuration of Individual Behavior</h4>

Each individual BGP protocol session instance, or BGP speaker, must be
configured separately.  The configuration of an individual BGP speaker takes
place within a <code>ProtocolSession</code> attribute (refer to attribute
<code>.schemas.graph.ProtocolSession</code> of the SSFNet schema (file
<code>ssfnet/examples/net.dml</code> in the SSFNet distribution)).  Such a
<code>ProtocolSession</code> attribute must have a subattribute
<code>name</code> with a value of <code>bgp</code> as well as a subattribute
<code>use</code> with a value of <code>SSF.OS.BGP4.BGPSession</code>.  A
minimal BGP <code>ProtocolSession</code> would look something like this:
</p>

<blockquote>
<pre>
ProtocolSession [
  name bgp
  use SSF.OS.BGP4.BGPSession
]
</pre>
</blockquote>

<p align="justify">
There are currently two basic options for configuring an individual BGP
speaker:
<ul>
  <li><b>Full Manual Configuration</b> This option requires that all attributes
  be fully configured in DML.  Most attributes must be configured specifically
  for each individual BGP instance, however, certain global defaults can be
  used to reduce repetition.  This is akin to configuring an actual router in a
  real network.

  <li><b>Autoconfiguration</b> This option leaves it to the simulator to
  perform automatic configuration of each attribute of all BGP instances.  This
  is useful in models which require the general functionality of inter-domain
  routing without variations in the details.  <i>Restrictions:</i> Because of
  its general nature, certain restrictions apply when autoconfiguration is in
  use.  If IBGP is used (that is, if there are ASes with more than one BGP
  router in them), then all routers running BGP in the same AS must be
  connected by a full mesh of physical links, and route reflection cannot be
  used.  Default values for all timers are used, and no policy configuration
  can be done.  <i>Configuration of defaults:</i> Global default values for
  certain attributes can still be configured even when autoconfiguration is in
  use.  Such attributes are indicated below.
</ul>
</p>

<p align="justify">
Figure 1 contains the schema for all attributes of BGP which are configurable
on a per-BGP speaker basis in this implementation.  (It is not <a
href="bgp-schema.dml">the complete schema</a>, though, which contains
additional global attributes, output options, and debugging options.)  The
tables following the figure contain detailed descriptions of each attribute and
their allowed usages.
</p>

<blockquote>
<b>Figure 1</b>&nbsp;&nbsp;SSFNet BGP-4 DML schema excerpt: <a href="schema-excerpt.html"
onClick="window.open('schema-excerpt.html','');return false">[new window]</a>
<a href="schema-excerpt.html">[same window]</a><br>
</blockquote>

<p align="justify">
Tables 1 through 3 summarize the individual behavioral attributes, and a fourth
table provides some additional details on policy configuration.  Table 1
describes attributes which appear immediately within the
<code>ProtocolSession</code> attribute.  Table 2 describes attributes which
appear immediately within the <code>neighbor</code> attribute.  Table 3
describes all attributes which apply to policy configuration.  Table 4 contains
usage information for configuring an atomic predicate in a policy rule.
</p>

<blockquote>
<b>Table 1</b>&nbsp;&nbsp;Immediate Subattributes of <code>ProtocolSession</code>: <a
href="table1.html" onClick="window.open('table1.html','');return false">[new
window]</a> <a href="table1.html">[same window]</a><br>
</blockquote>

<blockquote>
<b>Table 2</b>&nbsp;&nbsp;Immediate Subattributes of <code>neighbor</code>: <a
href="table2.html" onClick="window.open('table2.html','');return false">[new
window]</a> <a href="table2.html">[same window]</a><br>
</blockquote>

<blockquote>
<b>Table 3</b>&nbsp;&nbsp;Subattributes of <code>infilter</code> and
<code>outfilter</code>: <a href="table3.html"
onClick="window.open('table3.html','');return false">[new window]</a> <a
href="table3.html">[same window]</a><br>
</blockquote>

<blockquote>
<b>Table 4</b>&nbsp;&nbsp;Usage of <code>clause.predicate.atom</code>: <a
href="table4.html" onClick="window.open('table4.html','');return false">[new
window]</a> <a href="table4.html">[same window]</a><br>
</blockquote>

<p align="justify">
<code>ProtocolSession</code> blocks are in turn attributes of a
<code>graph</code> block (a protocol graph), which is an attribute of a
<code>router</code> configuration block.  That is, if the modeler would like to
configure the attributes of an instance of BGP with values other than the
defaults used in autoconfiguration, the appropriate
<code>ProtocolSession</code> attribute in the associated <code>router</code>
should contain the attributes to be configured.  (For example, if the modeler
wants router 123 to run BGP and wishes to set a value other than the default
for the Connect Retry Interval, then the DML configuration code in <a
href="examples/router123.dml"><code>router123.dml</code></a> could be used.)
</p>

<p align="justify">
Note that there are no compromises between the two configuration options.  That
is, when autoconfiguration is used, the modeler provides no information about a
BGP speaker, and when it is not used, the modeler must provide <i>all</i>
information about the BGP speaker (with possible exceptions when global default
attributes are in use).  In the above example (<a
href="examples/router123.dml"><code>router123.dml</code></a>), the
configuration of the BGP protocol session indicates that the BGP speaker has
one neighbor.  The relevant addresses, timer values, and filtering policy rules
are provided, even though they may be the same as the defaults used by
autoconfiguration.  Though it can be done, mixing autoconfigured and manually
configured BGP speakers should be avoided if possible.  It is least preferable
to mix them within the same AS--separating them by an AS boundary is less
likely to cause compatibility problems between the two configuration schemes.
</p>

<p align="justify">
<a href="examples/autoconfig.dml"><code>autoconfig.dml</code></a> and <a
href="examples/manualconfig.dml"><code>manualconfig.dml</code></a> are example
DML files, each of which configures a simple network of two directly connected
routers.  Autoconfiguration is used in the first but not the second.
</p>

<p align="justify">
When using manual configuration, the modeler may wish to use virtual (loopback)
interfaces, particularly for Internal BGP peering sessions.  A good example of
DML code which does this is in the validation test file <a
href="../test/loopback/loopback.dml"><code>BGP4/test/loopback/loopback.dml</code></a>.
</p>

<p align="justify">
For more examples of BGP configuration, see the <a
href="http://www.ssfnet.org/bgp/examples/">example simulations</a> on the
Internet and the <a href="validation.html">validation tests</a> included in
this distribution.  There are also several debugging options which were
intended for the developer but may be of use to the modeler in certain cases.
Refer to <a href="bgp-schema.dml">the full SSFNet BGP-4 DML schema</a>.
</p>

<h4>4.1.2 Configuration of Global Behavior</h4>

<p align="justify">
Certain global behavioral options exist to simplify configuration.  None of
them are required.  If used, however, they must appear immediately within the
<code>bgpoptions</code> attribute, which itself must appear immediately within
the top-level <code>Net</code> attribute.  Table 5 summarizes each of these
attributes.
</p>

<blockquote>
<b>Table 5</b>&nbsp;&nbsp;Global Behavioral DML Attributes: <a href="table5.html"
onClick="window.open('table5.html','');return false">[new window]</a> <a
href="table5.html">[same window]</a><br>
</blockquote>

<p align="justify">
For example, the <code>bgpoptions</code> attribute for a simulation which
changes the global values used for some of the BGP timers might look like this:
</p>

<blockquote>
<pre>
bgpoptions [
  global_ebgp_mrai 50
  global_keep_alive_time 100
]
</pre>
</blockquote>


<h4>4.2 Configuration of Presentation</h4>

<p align="justify">
Several options are available for configuring the presentation of BGP-related
output in an SSFNet simulation.  There are two independent types of output
which can be used during a simulation.  <i>Streamed output</i> sends output
records (messages) to a specified output file in a special encoded byte format.
<i>Printed output</i> sends records (messages) to the standard output stream.
Streamed output is good for models which produce large volumes of output, as it
is typically more time and space efficient.  However, it requires some
additional work in order to be useful.  First, any BGP router generating output
must be configured with an additional protocol session, called a probe, which
helps collect and multiplex the output.  Second, a separate program, called a
<i>player</i>, must be run in order to process the output stream.  Players of
any kind may be composed (in Java) to perform arbitrary analysis on the output
records.  Included with this distribution is a player which converts the byte
records into human-readable ASCII format (which is the same as the printed
output).  Printed output is much simpler, and is very useful for models with
smaller amounts of output, as well as for simple debugging.
</p>

<p align="justify">
Each output-related option can be specified in at least one of two places: in
the <code>bgpoptions</code> attribute (to give the attributes global scope), or
in the <code>monitor</code> attribute of a BGP session (so that the attribute
affects only that particular BGP session).  Table 6 lists the attributes
available for configuring presentation.  Most of the attributes can be used
both globally and locally, but some can only be used in one of the two ways
(they are noted as such in the table).
</p>

<blockquote>
<b>Table 6</b>&nbsp;&nbsp;DML Attributes for Presentation Configuration: <a
href="table6.html" onClick="window.open('table6.html','');return false">[new
window]</a> <a href="table6.html">[same window]</a><br>
</blockquote>

<p align="justify">
Global configuration looks much the same as for global configuration of
behavior (see section 4.1.2).  Local configuration might look something like
this:
</p>

<blockquote>
<pre>
ProtocolSession [
  name bgp
  use SSF.OS.BGP4.BGPSession
  monitor [
    show_snd_update true
    dump_loc_rib true
  ]
]
</pre>
</blockquote>


<h4>4.2.1 Configuring and Using Streamed Output</h4>

<p align="justify">
In order to send simulation output to an encoded byte stream (and ultimately to
a file), first the <code>streaming</code> option must be set to
<code>true</code> (see section 4.2 and Table 6).  In addition to this, each
router which generates BGP output must be configured to have one additional
protocol session in its protocol graph by way of an additional
<code>ProtocolSession</code> attribute.  This attribute must look as follows:
</p>

<blockquote>
<pre>
ProtocolSession [
  name probe
  use SSF.OS.ProbeSession
  file "some-file-name"
  stream "some-stream-name"
]
</pre>
</blockquote>

<p align="justify">
where <code>some-file-name</code> is a file name of your choice, and
<code>some-stream-name</code> is a stream name of your choice.  Currently, each
probe protocol session in a single model specification should use the same file
name throughout.  It should also use the same stream name throughout.  Refer to
<a href="streaming.dml"><code>streaming.dml</code></a> for a full DML model
which uses streaming.  When the simulation is complete, the file
<code>some-file-name.0</code> will have been created containing stream
<code>some-stream-name.0</code>.  (Note that two characters, a dot and a zero
(".0"), are appended to the file and stream names.)  To "play back" the
contents of the record stream, you may want to use the
<code>VerbosePlayer</code> program (in the <code>BGP4/Players/</code>
directory) like this:
</p>

<blockquote>
<table border="0" cellpadding="0" cellspacing="0"><tr><td align="left">
<pre>
java SSF.OS.BGP4.Players.VerbosePlayer some-file-name.0 some-stream-name.0
</pre>
</td></tr></table>
</blockquote>

<p align="justify">
This will print human-readable output corresponding to the byte-encoded output.
Additional customized players which perform arbitrary operations (analysis,
presentation, etc.) on output record streams can be composed.  Refer to
<code>AbstractPlayer.java</code> and <code>VerbosePlayer.java</code> in the
<code>BGP4/Players/</code> directory for an example of how this can be done.
</p>

<h4>4.3 Configuration of Optimizations</h4>

<p align="justify">
Several options exist in which functionality can be traded for improvements in
model execution.  In particular, memory improvements (which often lead to
shorter execution times) can often be gained in models which only use basic BGP
options.  Table 7 summarizes all of these options and their implications.
</p>

<blockquote>
<b>Table 7</b>&nbsp;&nbsp;DML Attributes for Optimizations Configuration: <a
href="table7.html" onClick="window.open('table7.html','');return false">[new
window]</a> <a href="table7.html">[same window]</a><br>
</blockquote>


<a name="src">
<h3>5 Source Code</h3>

<p>
Archived Java source: <a
href="http://www.ssfnet.org/bgp/"><code>http://www.ssfnet.org/bgp/</code></a><br>
Modification history: <a href="HISTORY">BGP4/doc/HISTORY</a><br>
</p>

<a name="examples">
<h3>6 Examples</h3>

<p>
Further examples are available on the Internet at <a
href="http://www.ssfnet.org/bgp/examples/"><code>http://www.ssfnet.org/bgp/examples/</code></a>
</p>

<a name="test">
<h3>7 Validation</h3>

<p align="justify">
No well-established method currently exists for validating an implementation of
BGP, so we began composing our own <a href="validation.html"> validation tests
for SSF.OS.BGP4</a>.  They vary from very simple, strict verifications of the
most basic behaviors of BGP to more macroscopic tests which check the general
characteristics of BGP in larger networks.
</p>

<a name="faq">
<h3>8 Questions and Help</h3>

<p align="justify">
SSFNet uses an interactive FAQ (the SSFNet Faq-O-Matic) which contains several
answers to frequently asked questions about SSFNet and all of its components,
including SSF.OS.BGP4.  Users can also log in and post new questions, which
others in the SSFNet modeling community can respond to by posting their own
answers.  The SSFNet Faq-O-Matic is located at <a
href="http://www.cs.dartmouth.edu/research/ssfnet/faq/fom.cgi">http://www.cs.dartmouth.edu/research/ssfnet/faq/fom.cgi</a>.
</p>

<a name="references">
<h3>9 References</h3>

<p>
<a name="ref1">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[1]
<font face="fixed">&nbsp;&nbsp;</font><a href="http://www.ietf.cnri.reston.va.us/rfc/rfc1771.txt">RFC 1771: A Border Gateway Protocol 4 (BGP-4)</a><br>
</p>

<p>
<a name="ref2">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[2]
<font face="fixed">&nbsp;&nbsp;</font><a href="http://www.ietf.cnri.reston.va.us/rfc/rfc1657.txt">RFC 1557: Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2</a><br>
</p>

<p>
<a name="ref3">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[3]
<font face="fixed">&nbsp;&nbsp;</font><a href="http://www.ietf.cnri.reston.va.us/rfc/rfc1772.txt">RFC 1772: Application of the Border Gateway Protocol in the Internet</a><br>
</p>

<p>
<a name="ref4">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[4]
<font face="fixed">&nbsp;&nbsp;</font><a href="http://www.ietf.cnri.reston.va.us/rfc/rfc1773.txt">RFC 1773: Experience with the BGP-4 protocol</a><br>
</p>

<p>
<a name="ref5">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[5]
<font face="fixed">&nbsp;&nbsp;</font><a href="http://www.ietf.cnri.reston.va.us/rfc/rfc1774.txt">RFC 1774: BGP-4 Protocol Analysis</a><br>
</p>

<p>
<a name="ref6">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[6]
<font face="fixed">&nbsp;&nbsp;</font><a href="http://www.ietf.cnri.reston.va.us/rfc/rfc2796.txt">RFC 2796: BGP Route Reflection--An Alternative to Full Mesh IBGP</a><br>
</p>

<p>
<a name="ref7">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[7]
<font face="fixed">&nbsp;&nbsp;</font><font color="blue"><i>BGP4: Inter-Domain Routing in the Internet</i></font> by John W. Stewart III<br>
</p>

<p>
<a name="ref8">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[8]
<font face="fixed">&nbsp;&nbsp;</font><font color="blue"><i>Internet Routing Architectures</i></font> by Bassam Halabi<br>
</p>

<p>
<a name="ref9">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[9]
<font face="fixed">&nbsp;&nbsp;</font><a href="http://www.ietf.cnri.reston.va.us/rfc/rfc2439.txt">RFC 2439: BGP Route Flap Damping</a><br>
</p>

<p>
<a name="ref10">
<font face="fixed">&nbsp;&nbsp;&nbsp;</font>[10]
<font face="fixed">&nbsp;</font><a href="ftp://ftp.ripe.net/ripe/docs/ripe-210.txt">RIPE 210: RIPE Routing-WG Recommendation for coordinated route-flap damping parameters</a><br>
</p>

<a name="about">
<h3>10 Authors</h3>

<p>
BJ Premore is the primary author of SSF.OS.BGP4.  The route flap damping code
was contributed by Z. Morley Mao.
</p>

<pre>










































































</pre>


</body>
</html>
